\section{Related Work} 
\label{sec:related_work}
\begin{comment}
Descriptions of and references to related work such as for example the work by Kortuem \cite{proem2001} or Zhou \cite{zhou2001:semp2p1}.  Remember! You \emph{must} have an adequate related work section.  Excellent sources for literature are Google Scholar\footnote{\url{http://scholar.google.com/}} (enable ``Show links to import citations into BibTeX'' under Preferences), ACM Library\footnote{\url{http://portal.acm.org/}}, and IEEE Xplore\footnote{\url{http://ieeexplore.ieee.org/}}.  The latter two may only be available through the department's network---use VPN from home.  References to literature should always be handled as in this document---URLs may be put into footnotes, but \emph{never} literature references.
\end{comment}

\begin{comment}
\textbf{Workshop on Economics of Peer-to-Peer systems} - 2003

\textbf{Dissecting bittorrent: Five months in a torrent's lifetime} - 2004 x

\textbf{BASS} - 2006 x

\textbf{Understanding user behavior in large-scale video-on-demand systems} - 2006

\textbf{BiToS} - 2007 x

\textbf{Is high-quality VOD feasible using P2P swarming?} - 2007 x

\textbf{Peer-to-peer multimedia streaming using BitTorrent} - 2007 x

\textbf{Challenges, design and analysis of a large-scale p2p-vod system} - 2008 x

\textbf{Watch Global, Cache Local: YouTube Network Traffic at a Campus Network - Measurements and Implications} - 2008 x

\textbf{Windowing BitTorrent for Video-on-Demand: Not All is Lost with Tit-for-Tat} - 2008 x
\end{comment}

BitTorrent is a P2P application that capitalizes the resources, e.g. access bandwidth and disk storage, of peer nodes to distribute large contents \cite{Izal:2004sp}. The single objective of BitTorrent is to quickly replicate a single large file to a set of clients, meaning that BitTorrents goal is to maximize the speed of this replication. This speed relies among other things on the chunk picking strategy implemented by the different peers, which in a BitTorrent client following the BitTorrent protocol, is rarest-first.
The rarest-first chunk picking strategy is however not suited for VoD services, since the different chunks are not requested in an order which makes it possible to start viewing a video before a download has ended. 

To handle this \cite{dana2006bass} proposed a novel streaming system called BitTorrent Assisted Streaming System, in short BASS, for VoD services, where the use of an external streaming server is added to a slightly modified BitTorrent system. It is important to notice that simply forcing the BitTorrent system to request chunks sequentially would have disastrous results because then clients would only contain subsets of each others data and tit-for-tat would fail \cite{dana2006bass}. BASS uses an external media server with the only modification to BitTorrent being that it does not download any data prior to the current playback point. It is allowed to use the rarest-first and tit-for-tat policies, as long as it is before the current playback point.

\cite{vlavianos2007bitos} describes a so-called "view-as-you-download service" based on BitTorrent. The algorithm used in this article is based on three sets, the first being a set containing the received chunks, meaning it contains all chunks which the current peer has downloaded for the current torrent. The second set being a high priority set, meaning a set containing all the chunks which the player needs in the nearest future. The last and third set is a set containing all remaining chunks, meaning all the chunks which have not yet been downloaded and have not yet been added to the high priority set. Notice that the different chunks in the high priority set are downloaded using the rarest-first algorithm.
The idea of a high priority set is also introduced in \cite{shah2007peer}, however with the difference that \cite{vlavianos2007bitos} also mentions that it could give an advantage to modify the tracker, e.g. instead of returning a random list of peers the peers could be picked according to other criteria.

The reason that the rarest-first algorithm is used within the high priority set is to utilize as many system resources as possible. This notion of system utilization in VoD services is furthermore explored in \cite{annapureddy2007high}, where different algorithms are explored with regards to their throughput (system utilization) and their goodput (videos view-ability). It is observed that the algorithm which provides the best throughput and goodput is an algorithm which splits a file up into segments each containing a number of chunks. Two segments are picked using heuristics, such as where in the video the user is at the current moment. A chunk is now picked using rarest-first strategy in one of these two segments, furthermore the segment to perform rarest-first in is picked using a biased coin where the first segment has a probability of 90 percent and the second a probability of 10 percent.

In \cite{vlavianos2007bitos} it is mentioned as a possibility to modify the algorithm such that chunks are requested with a certain probability (p) within the high priority set and with probability 1-p outside the high priority set, meaning that the sliding window of \cite{vlavianos2007bitos} in theory could expand to the end of the file, with this modification. \cite{savolainen2008windowing} suggest setting an upper limit of the sliding window size, thereby forcing the system to, at some point, request all chunks within the window before moving on.

Given the existence of fast-forwarding functions in most common DVD players this function is also expected in VoD systems. This concept is among others described in \cite{huang2008challenges} where a large scale P2P VoD system is explored and analyzed. In this paper the analyzed system uses a sequential chunk picking algorithm as first priority and a rarest first chunk picker as second priority. A third, not yet implemented, option is an anchor-based approach, which allows the user to fast-forward to a specific anchor which is ready. The approach is not implemented in the paper because, according to the paper, each user only fast-forwards, on average, 1.8 times.

Another interesting aspect of VoD systems is the notion of local popularity, as mentioned in \cite{zink2008watch}, meaning that content which is popular in a global context is not necessarily popular in a local context. The paper suggests a local cache in order to reduce the server load on YouTube. This cache could be distributed in the form of a P2P network, which resulted in an overall better performance and smaller server load.